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Abstract 


This document describes a method that allows parties to 
electronically sign Routing Policy Specification Language objects and 
validate such electronic signatures. This allows relying parties to 
detect accidental or malicious modifications of such objects. It 
also allows parties who run Internet Routing Registries or similar 
databases, but do not yet have authentication (based on Routing 
Policy System Security) of the maintainers of certain objects, to 
verify that the additions or modifications of such database objects 
are done by the legitimate holder(s) of the Internet resources 
mentioned in those objects. This document updates RFCs 2622 and 4012 
to add the signature attribute to supported RPSL objects. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7909. 
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Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 


(http://trustee.ietf.org/license-info) 


publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with 
document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


Objects stored in resource databases, like the RIPE DB, are generally 
protected by an authentication mechanism: anyone creating or 
modifying an object in the database has to have proper authorization 
to do so, and therefore has to go through an authentication procedure 
(provide a password, certificate, email signature, etc.). However, 
for objects transferred between resource databases, the 
authentication is not guaranteed. This means that when a Routing 
Policy Specification Language (RPSL) object is downloaded from a 
database, the consumer can reasonably claim that the object is 
authentic if it was locally created, but cannot make the same claim 
for an object imported from a different database. Also, once such an 
object is downloaded from the database, it becomes a simple (but 
still structured) text file with no integrity protection. More 
importantly, the authentication and integrity guarantees associated 
with these objects do not always ensure that the entity that 
generated them is authorized to make the assertions implied by the 
data contained in the objects. 


A potential use for resource certificates [RFC6487] is to use them to 
secure such (both imported and downloaded) database objects, by 
applying a digital signature over the object contents in lieu of 
methods such as Routing Policy System Security [RFC2725]. The signer 
of such signed database objects MUST possess a relevant resource 
certificate, which shows him/her as the legitimate holder of an 
Internet number resource. This mechanism allows the users of such 
database objects to verify that the contents are in fact produced by 
the legitimate holder(s) of the Internet resources mentioned in those 
objects. It also allows the signatures to cover whole RPSL objects, 
or just selected attributes of them. In other words, a digital 
signature created using the private key associated with a resource 
certificate can offer object security in addition to the channel 
security already present in most resource databases. Object security 
in turn allows such objects to be hosted in different databases and 
still be independently verifiable. 


While the approach outlined in this document mandates the use of the 
Resource Public Key Infrastructure (RPKI) for certificate 
distribution, it is not dependent upon the RPKI for correct 
functionality. Equivalent functionality can be achieved with a more 
traditional Certification Authority (CA), using the extensions 
described in [RFC3779] within the certificates, and the appropriate 
trust anchor material to verify the digital signature. 
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The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


2. Signature Syntax and Semantics 


When signing an RPSL object [RFC2622] [RFC4012], the input for the 
signature process is transformed into a sequence of strings of ASCII 
data. The approach is similar to the one used in Domain Key 
Identified Mail (DKIM) [RFC6376]. In the case of RPSL, the object to 
be signed closely resembles an SMTP header, so it seems reasonable to 
adapt DKIM’s relevant features. 


2.1. General Attributes and Meta Information 


The digital signature associated with an RPSL object is itself a new 


attribute named "Signature". It consists of mandatory and optional 
fields. These fields are structured in a sequence of name and value 
pairs, separated by a semicolon ";" and a whitespace. Collectively, 


these fields make up the value for the new "Signature" attribute. 

The "name" part of such a component is always a single ASCII 
character that serves as an identifier; the value is an ASCII string 
the contents of which depend on the field type. Mandatory fields 
MUST appear exactly once, whereas optional fields MUST appear at most 
once. 


Mandatory fields of the "Signature" attribute: 


o Version of the signature (field "v"): This field MUST be set to 
"rpkivl" and MAY be the first field of the signature attribute to 
simplify the parsing of the attributes’ fields. The signature 
format described in this document applies when the version field 
is set to "rpkivi". All the rest of the signature attributes are 
defined by the value of the version field. 


o Reference to the certificate corresponding to the private key used 
to sign this object (field "c"): The value of this field MUST be a 
URL of type "rsync" [RFC5781] or "http(s)" [RFC7230] that points 
to a specific resource certificate in an RPKI repository 
[RFC6481]. Any non URL-safe characters (including semicolon ";" 
and plus "+") must be URL encoded [RFC3986]. 


o Signature method (field "m"): What hash and signature algorithms 
were used to create the signature. This specification follows the 
algorithms defined in RFC 6485 [RFC6485]. The algorithms are 


referenced within the signature attribute by the ASCII names of 
the algorithms. 


Kisteleki & Haberman Standards Track [Page 4] 


RFC 7909 Securing RPSL June 2016 


o Time of signing (field "t"): The format of the value of this field 
MUST be in the Internet Date/Time ABNF format [RFC3339]. All 
times MUST be converted to Universal Coordinated Time (UTC), i.e., 
the ABNF time-offset is always "zZz". 


o The signed attributes (field "a"): This is a list of attribute 
names, separated by an ASCII "+" character (if more than one 
attribute is enumerated). The list must include any attribute at 


most once. 


o The signature itself (field "b"): This MUST be the last field in 
the list. The signature is the output of the signature algorithm 
using the appropriate private key and the calculated hash value of 
the object as inputs. The value of this field is the digital 
signature in base64 encoding (Section 4 of [RFC4648]). 


Optional fields of the "signature" attribute: 


o Signature expiration time (field "x"): The format of the value of 
this field MUST be in the Internet Date/Time format [RFC3339]. 
All times MUST be represented in UTC. 


2.2. Signed Attributes 


One can look at an RPSL object as an (ordered) set of attributes, 
each having a "key: value" syntax. Understanding this structure can 
help in developing more flexible methods for applying digital 
signatures. 


Some of these attributes are automatically added by the database, 
some are database-dependent, yet others do not carry operationally 
important information. This specification allows the maintainer of 
such an object to decide which attributes are important (signed) and 
which are not (not signed), from among all the attributes of the 
object; in other words, we define a way of including important 
attributes while excluding irrelevant ones. Allowing the maintainer 
of an object to select the attributes that are covered by the digital 
signature achieves the goals established in Section 1. 


The type of the object determines the minimum set of attributes that 
MUST be signed. The signer MAY choose to sign additional attributes, 
in order to provide integrity protection for those attributes too. 


When verifying the signature of an object, the verifier has to check 
whether the signature itself is valid, and whether all the specified 
attributes are referenced in the signature. If not, the verifier 
MUST reject the signature and treat the object as a regular, unsigned 
RPSL object. 
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2.3. Storage of the Signature Data 


The result of applying the signature mechanism once is exactly one 
new attribute for the object. As an illustration, the structure of a 
signed RPSL object is as follows: 


attributel: valuel 
attribute2: value2 
attribute3: value3 


signature: v=rpkivl; c=rsync://..... ; m=sha256WithRSAEncryption; 
t=2014-12-31T23:59:602; 
a=attributeltattribute2+attribute3t+...; 
b=<base64 data> 


2.4. Number Resource Coverage 


Even if the signature over the object is valid according to the 
signature validation rules, it may not be relevant to the object; it 
also needs to cover the relevant Internet number resources mentioned 
in the object. 


Therefore, the Internet number resources present in [RFC3779] 
extensions of the certificate referred to in the "c" field of the 
signature MUST cover the resources in the primary key of the object 
(e.g., value of the "aut-num:" attribute of an aut-num object, value 
of the "inetnum:" attribute of an inetnum object, values of "route:", 
and "origin:" attributes of a route object, etc.). 


2.5. Validity Time of the Signature 


The validity time interval of a signature is the intersection of the 
validity time of the certificate used to verify the signature, the 
"not before" time specified by the "t" field of the signature, and 
the optional "not after" time specified by the "x" field of the 
signature. 


When checking multiple signatures, these checks are individually 
applied to each signature. 


3. Signature Creation and Validation Steps 

3.1. Canonicalization 
The notion of canonicalization is essential to digital signature 
generation and validation whenever data representations may change 


between a signer and one or more signature verifiers. 
Canonicalization defines how one transforms a representation of data 
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into a series of bits for signature generation and verification. The 

task of canonicalization is to make irrelevant differences in 

representations of the same object, which would otherwise cause 

Signature verification to fail. Examples of this could be: 

o data transformations applied by the databases that host these 
objects (such as notational changes for IPv4/IPv6 prefixes, 
automatic addition/modification of "changed" attributes, etc.) 

o the difference of line terminators across different systems 

This means that the destination database might change parts of the 

submitted data after it was signed, which would cause signature 

verification to fail. This document specifies strict 
canonicalization rules to overcome this problem. 

The following steps MUST be applied in order to achieve canonicalized 

representation of an object, before the actual signature 

(verification) process can begin: 

1. Comments (anything beginning with a "#") MUST be omitted. 

2. Any trailing whitespace MUST be omitted. 


3. A multi-line attribute MUST be converted into its single-line 
equivalent. This is accomplished by: 


* Converting all line endings to a single blank space (ASCII 
code 32). 


* Concatenating all lines into a single line. 


* Replacing the trailing blank space with a single new line 
("\n", ASCII code 10). 


4. Numerical fields MUST be converted to canonical representations. 
These include: 


* Date and time fields MUST be converted to UTC and MUST be 
represented in the Internet Date/Time format [RFC3339]. 


* AS numbers MUST be converted to ASPLAIN syntax [RFC5396]. 
*  IPv6 addresses MUST be canonicalized as defined in [RFC5952]. 


* IPv4 addresses MUST be represented as the ipv4-address type 
defined by RPSL [RFC2622]. 
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36276 


* All IP prefixes (IPv4 and IPv6) MUST be represented in 
Classless Inter-Domain Routing (CIDR) notation [RFC4632]. 


All ranges, lists, or sets of numerical fields are represented 
using the appropriate RPSL attribute and each numerical element 
contained within those attributes MUST conform to the 
canonicalization rules in this document. The ordering of values 
within such fields MUST be maintained during database transfers. 


The name of each attribute MUST be converted into lower case, and 
MUST be kept as part of the attribute line. 


Tab characters ("\t", ASCII code 09) MUST be converted into 
spaces. 


Multiple whitespaces MUST be collapsed into a single space (" ", 
ASCII code 32) character. 


All line endings MUST be converted into a single new line ("\n", 
ASCII code 10) character, (thus avoiding CR vs. CRLF 


differences). 


Signature Creation 


Given an RPSL object and corresponding certificate, in order to 
create the digital signature, the following steps MUST be performed: 


T 


Create a list of attribute names referring to the attributes that 
will be signed (contents of the "a" field). The minimum set of 
these attributes is determined by the object type; the signer MAY 
select additional attributes. 


Arrange the selected attributes according to the selection 
sequence specified in the "a" field as above, omitting all 
attributes that will not be signed. 


Construct the new "signature" attribute, with all its fields, 
leaving the value of the "b" field empty. 


Apply canonicalization rules to the result (including the 
"signature" attribute). 


Create the signature over the results of the canonicalization 
process (according to the signature and hash algorithms specified 
in the "m" field of the signature attribute). 


Insert the base64-encoded value of the signature as the value of 
the "b" field. 
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7. 


3:23 


Append the resulting "Signature" attribute to the original 
object. 


Signature Validation 


In order to validate a signature over such an object, the following 
steps MUST be performed: 


Ls 


Verify the syntax of the "Signature" attribute (i.e., whether it 
contains the mandatory and optional components and the syntax of 
these fields matches the specification as described in 

Section 2.1). 


Fetch the certificate referred to in the "c" field of the 
"Signature" attribute, and check its validity using the steps 
described in [RFC6487]. 


Extract the list of attributes that were signed using the signer 
from the "a" field of the "Signature" attribute. 


Verify that the list of signed attributes includes the minimum 
set of attributes for that object type. 


Arrange the selected attributes according to the selection 
sequence provided in the value of the "a" field, omitting all 
unsigned attributes. 


Replace the value of the signature field "b" of the "signature" 
attribute with an empty string. 


Apply the canonicalization procedure to the selected attributes 
(including the "Signature" attribute). 


Check the validity of the signature using the signature algorithm 
specified in the "m" field of the signature attribute, the public 
key contained in the certificate mentioned in the "c" field of 
the signature, the signature value specified in the "b" field of 
the signature attribute, and the output of the canonicalization 
process. 


Signed Object Types and Set of Signed Attributes 


This section describes a list of object types that MAY be signed 
using this approach. For each object type, the set of attributes 
that MUST be signed for these object types (the minimum set noted in 
Section 3.3 is enumerated. 
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This list generally excludes attributes that are used to maintain 
referential integrity in the databases that carry these objects, 
since these usually make sense only within the context of such a 
database, whereas the scope of the signatures is only one specific 
object. Since the attributes in the referred object (such as mnt-by, 
admin-c, tech-c, etc.) can change without any modifications to the 
signed object, signing such attributes could lead to a false sense of 
security in terms of the contents of the signed data; therefore, 
including such attributes should only be done in order to provide 
full integrity protection of the object itself. 


The newly constructed "Signature" attribute is always included in the 
list. The signature under construction MUST NOT include signature 
attributes that are already present in the object. 


as-block: 
* as-block 
* signature 
aut-num: 


aut-num 
as-name 
member-of 
import 
mp-import 
export 
mp-export 
default 
mp-default 
signature 


+ + + F FF E F F F 


inet [6]num: 


inet [6]num 
netname 
country 
status 
signature 


+ + + F 
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route[6]: 


route [6] 
origin 
holes 
member-of 
signature 


+ + F F 


It should be noted that the approach defined in this document has a 
limitation in signing route[6] objects. This document only supports 
a single signature per object. This means that it is not possible to 
properly sign route[6] objects where one resource holder possesses 
the Autonomous System Number (ASN) and another resource holder 
possesses the referenced prefix. A future version of this 
specification may resolve this limitation. 


For each signature, the extension described in RFC 3779 that appears 
in the certificate used to verify the signature MUST include a 
resource entry that is equivalent to, or covers (i.e., is "less 
specific" than) the following resources mentioned in the object the 
signature is attached to: 


o For the as-block object type: the resource in the "as-—block" 
attribute. 


o For the aut-num object type: the resource in the "aut-num" 
attribute. 


o For the inet [6]num object type: the resource in the "inet[6]num" 
attribute. 


o For the route[6] object type: the resource in the "route[6]" or 
"origin" (or both) attributes. 


5. Keys and Certificates Used for Signature and Verification 


The certificate that is referred to in the signature (in the "c" 
field): 


o MUST be an end-entity (i.e., non-CA) certificate 


o MUST conform to the X.509 PKIX Resource Certificate profile 
[RFC6487] 


o MUST have the extension described in RFC 3779 that covers the 
Internet number resource included in a signed attribute [RFC3779] 
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The certificate generated will omit the Subject Information Access 
(SIA) extension mandated by RFC 6487 as that extension requires an 
rsync URI for the accessLocation form and RPSL currently does not 
support database access via rsync. 


6. Security Considerations 


RPSL objects stored in the Internet Routing Registry (IRR) databases 
are public, and as such there is no need for confidentiality. Each 
signed RPSL object can have its integrity and authenticity verified 
using the supplied digital signature and the referenced certificate. 


Since the RPSL signature approach leverages X.509 extensions, the 
security considerations in [RFC3779] apply here as well. 
Additionally, implementers MUST follow the certificate validation 
steps described in RFC 6487. 


The maintainer of an object has the ability to include attributes in 
the signature that are not included in the resource certificate used 
to create the signature. Potentially, a maintainer may include 
attributes that reference resources the maintainer is not authorized 
to use. 


It should be noted that this digital signature does not preclude 
monkey-in-the-middle attacks where the adversary either intercepts 
RPSL object transfers, deletes the signature attribute, modifies the 
contents, or intercepts the transfer and drops the objects destined 
for the requester. 
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